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The ’acct’ URI Scheme 
Abstract 
This document defines the ’acct’ Uniform Resource Identifier (URI) 
scheme as a way to identify a user’s account at a service provider, 
irrespective of the particular protocols that can be used to interact 
with the account. 
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1. Introduction 


Existing Uniform Resource Identifier (URI) schemes that enable 
interaction with, or that identify resources associated with, a 
user’s account at a service provider are tied to particular services 
or application protocols. Two examples are the ’mailto’ scheme 
(which enables interaction with a user’s email account) and the 
‘http’ scheme (which enables retrieval of web files controlled by a 
user or interaction with interfaces providing information about a 


user). However, there exists no URI scheme that generically 
identifies a user’s account at a service provider without specifying 
a particular protocol to use when interacting with the account. This 


specification fills that gap. 
2. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in 
[RFC2119]. 


3. Rationale 


During formalization of the WebFinger protocol [RFC7033], much 
discussion occurred regarding the appropriate URI scheme to include 
when specifying a user’s account as a web link [RFC5988]. Although 
both the ’mailto’ [RFC6068] and ’http’ [RFC7230] schemes were 
proposed, not all service providers offer email services or web 
interfaces on behalf of user accounts (e.g., a microblogging or 
instant messaging provider might not offer email services, or an 
enterprise might not offer HTTP interfaces to information about its 
employees). Therefore, the participants in the discussion recognized 
that it would be helpful to define a URI scheme that could be used to 
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generically identify a user’s account at a service provider, 
irrespective of the particular application protocols used to interact 
with the account. The result was the ’acct’ URI scheme defined in 
this document. 


(Note that a user is not necessarily a human; it could be an 
automated application such as a bot, a role-based alias, etc. 
However, an ‘’acct’ URI is always used to identify something that has 
an account at a service, not the service itself.) 


4. Definition 


The syntax of the ’acct’ URI scheme is defined under Section 7 of 
this document. Although ’acct’ URIs take the form "user@host", the 
scheme is designed for the purpose of identification instead of 
interaction (regarding this distinction, see Section 1.2.2 of 
[RFC3986]). The "Internet resource" identified by an ’acct’ URI is a 
user’s account hosted at a service provider, where the service 
provider is typically associated with a DNS domain name. Thus, a 
particular ’acct’ URI is formed by setting the "user" portion to the 
user’s account name at the service provider and by setting the "host" 
portion to the DNS domain name of the service provider. 


Consider the case of a user with an account name of "foobar" ona 
microblogging service "Status.example.net". It is taken as 
convention that the string "foobar@status.example.net" designates 
that account. This is expressed as a URI using the ’acct’ scheme as 
"acct: foobar@status.example.net". 


A common scenario is for a user to register with a service provider 
using an identifier (such as an email address) that is associated 
with some other service provider. For example, a user with the email 
address "juliet@capulet.example" might register with a commerce 
website whose domain name is "shoppingsite.example". In order to use 
her email address as the localpart of the ’acct’ URI, the at-sign 
character (U+0040) needs to be percent-encoded as described in 
[RFC3986]. Thus, the resulting ’acct’ URI would be 

"acct: juliet %40capulet.example@shoppingsite.example". 


It is not assumed that an entity will necessarily be able to interact 
with a user’s account using any particular application protocol, such 
as email; to enable such interaction, an entity would need to use the 
appropriate URI scheme for such a protocol, such as the ’mailto’ 
scheme. While it might be true that the ’acct’ URI minus the scheme 
name (e.g., "“user@example.com" derived from "acct:user@example.com") 
can be reached via email or some other application protocol, that 
fact would be purely contingent and dependent upon the deployment 
practices of the provider. 
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Because an ‘acct’ URI enables abstract identification only and not 
interaction, this specification provides no method for dereferencing 
an ’acct’ URI on its own, e.g., as the value of the /href’ attribute 
of an HTML anchor element. For example, there is no behavior 
specified in this document for an ’acct’ URI used as follows: 


<a href=’ acct:bob@example.com’>find out more</a> 


Any protocol that uses ’acct’ URIs is responsible for specifying how 
an ’acct’ URI is employed in the context of that protocol (in 
particular, how it is dereferenced or resolved; see [RFC3986]). Asa 
concrete example, an "Account Information" application of the 
WebFinger protocol [RFC7033] might take an ’acct’ URI, resolve the 
host portion to find a WebFinger server, and then pass the ’acct’ URI 
as a parameter in a WebFinger HTTP request for metadata (i.e., web 
links [RFC5988]) about the resource. For example: 


GET /.well-known/webfinger?resource=acct %3Abob%40example.com HTTP/1.1 


The service retrieves the metadata associated with the account 
identified by that URI and then provides that metadata to the 
requesting entity in an HTTP response. 


If an application needs to compare two ’acct’ URIs (e.g., for 
purposes of authentication and authorization), it MUST do so using 
case normalization and percent-encoding normalization as specified in 
Sections 6.2.2.1 and 6.2.2.2 of [RFC3986]. 


5. Security Considerations 


Because the ‘acct’ URI scheme does not directly enable interaction 
with a user’s account at a service provider, direct security concerns 
are minimized. 


However, an ‘’acct’ URI does provide proof of existence of the 
account; this implies that harvesting published ’acct’ URIs could 
prove useful to spammers and similar attackers -- for example, if 
they can use an ’acct’ URI to leverage more information about the 
account (e.g., via WebFinger) or if they can interact with protocol- 
specific URIs (such as /’/mailto’ URIs) whose user@host portion is the 
same as that of the ’acct’ URI. 


In addition, protocols that make use of ’acct’ URIs are responsible 
for defining security considerations related to such usage, e.g., the 
risks involved in dereferencing an ‘’acct’ URI, the authentication and 
authorization methods that could be used to control access to 
personal data associated with a user’s account at a service, and 
methods for ensuring the confidentiality of such information. 
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The use of percent-encoding allows a wider range of characters in 
account names but introduces some additional risks. Implementers are 
advised to disallow percent-encoded characters or sequences that 
would (1) result in space, null, control, or other characters that 
are otherwise forbidden, (2) allow unauthorized access to private 
data, or (3) lead to other security vulnerabilities. 


6. Internationalization Considerations 


As specified in [RFC3986], the ’acct’ URI scheme allows any character 
from the Unicode repertoire [Unicode] encoded as UTF-8 [RFC3629] and 
then percent-encoded into valid ASCII [RFC20]. Before applying any 
percent-encoding, an application MUST ensure the following about the 
string that is used as input to the URI-construction process: 


o The userpart consists only of Unicode code points that conform to 
the PRECIS IdentifierClass specified in [RFC7564]. 


o The host consists only of Unicode code points that conform to the 
rules specified in [RFC5892]. 


o Internationalized domain name (IDN) labels are encoded as A-labels 
[RFC5890]. 


7. IANA Considerations 
In accordance with the guidelines and registration procedures for new 
URI schemes [RFC4395], this section provides the information needed 
to register the ’acct’ URI scheme. 
URI Scheme Name: acct 
Status: permanent 
URI Scheme Syntax: The ’acct’ URI syntax is defined here in 


Augmented Backus-Naur Form (ABNF) [RFC5234], borrowing the 'host’, 
"pct-encoded’, ’sub-delims’, and ’unreserved’ rules from 


[RFC3986]: 
acctURI = "acct" ":" userpart "@" host 
userpart = unreserved / sub-delims 


0*( unreserved / pct-encoded / sub-delims ) 


Note that additional rules regarding the strings that are used as 
input to construction of ‘’acct’ URIs further limit the characters 
that can be percent-encoded; see the Encoding Considerations as 
well as Section 6 of this document. 
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8. 


8. 


URI Scheme Semantics: The ’acct’ URI scheme identifies accounts 
hosted at service providers. It is used only for identification, 
not interaction. A protocol that employs the ’acct’ URI scheme is 
responsible for specifying how an ’acct’ URI is dereferenced in 
the context of that protocol. There is no media type associated 
with the ’acct’ URI scheme. 


Encoding Considerations: See Section 6 of this document. 

Applications/Protocols That Use This URI Scheme Name: At the time of 
this writing, only the WebFinger protocol uses the ‘acct’ URI 
scheme. However, use is not restricted to the WebFinger protocol, 
and the scheme might be considered for use in other protocols. 


Interoperability Considerations: There are no known interoperability 
concerns related to use of the ’acct’ URI scheme. 


Security Considerations: See Section 5 of this document. 
Contact: Peter Saint-Andre, peter@andyet.com 


Author/Change Controller: This scheme is registered under the IETF 
tree. As such, the IETF maintains change control. 


References: None. 
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